System and method of authorizing execution of software code based on at least one installed profile

ABSTRACT

Embodiments include systems and methods for authorizing software code to be executed or access capabilities in secure operating environments. Profiles may be issued by trusted entities to extend trust to other entities to allow those other entities to provide or control execution of applications in a secure operating environment such as on particular computing devices. The profiles allow entities to add software code to the device without reauthorizing each distribution by a trusted authority such as testing, quality assurance, or to limited groups of devices controlled or authorized by the other entities.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of co-pending U.S. patentapplication Ser. No. 12/398,001, filed on Mar. 4, 2009, which claims thebenefit of U.S. Provisional Patent Application No. 61/033,735, filed onMar. 4, 2008, which is hereby incorporated by reference in its entirety.

BACKGROUND

Field

This application relates to controlling execution of software code.

Description of the Related Technology

Computing devices may be configured to require that code executed on thecomputer system be authorized by a trusted party. For example, suchauthorization may be used to help ensure that the integrity of thecomputing device is not compromised by malicious or unauthorized code.In some cases, computing devices may be configured to require that codebe digitally signed by the trusted party and verified in order to beexecuted on the computing device and/or to control execution of softwarethat accesses particular resources or services of the device.Verification of the digital signature helps to ensure that theunderlying application code has not been modified since it was digitallysigned by trusted authority 102. However, this security scheme presentschallenges in allowing multiple entities to implement their policies onthe device.

For example, during development, a software developer will frequentlymodify their code on a computer system and may attempt to test it onthat system. Each time the code may be modified, the digital signaturebecomes invalid. Therefore, in order to execute any new or modifiedcode, the software developer must have that code signed again by trustedauthority 102. This process can be cumbersome and time consuming.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an example of a computingenvironment in, which software code is distributed from one or moredevelopers to computing devices.

FIG. 2 is a block diagram illustrating one embodiment of softwarecomponents of a computing device in an environment such as illustratedin FIG. 1.

FIG. 3 is a block diagram illustrating one embodiment of a profile forcontrolling execution of software on a device such as illustrated inFIG. 2.

FIG. 4 is a block diagram illustrating data flow between softwarecomponents of one embodiment of the computing device illustrated in FIG.2.

FIG. 5 is a flowchart illustrating on embodiment of a method ofexecuting software based on profiles such as illustrated in FIG. 2.

FIG. 6 is a flowchart illustrating portions of the method of FIG. 5 inmore detail.

FIG. 7 is a block diagram illustrating one example of a computing devicesuch as illustrated in FIG. 2.

FIGS. 8A and 8B are block diagrams illustrating one example of acomputing device such as illustrated in FIG. 2.

FIG. 9 is a block diagram illustrating one example of an implementationof a mobile device such as illustrated in FIGS. 8A and 8B.

DETAILED DESCRIPTION

Embodiments are provided, which allow software developers to havecertain trusted rights in developing and controlling the execution ofsoftware on a device. In a computing device in, which applications arecryptographically signed by a first trusted party, a developer profilemay be provided that provisions operation of the device to extend trustto applications signed by a second party for a specified list of devicesidentified by device identifiers. A particular profile may enableapplications to run on a device from multiple developers, run onmultiple devices, and specify different available capabilities fordifferent devices, profiles, and/or developers.

Control of application execution may be maintained in a trusted space ofa processor of the device. The trusted space may include a privileged orsupervisor mode or memory space of the processor, such as kernel spaceof the memory. A service (or process) running in untrusted space, suchas user space of memory, may be configured to manage profiles anddetermine whether a particular application is executable and identifytrusted applications to the trusted space. The untrusted space mayinclude a memory space of a user-mode or unprivileged process executingon the processor.

Cryptographic functions and their accompanying calculations may beperformed by the user space service. In addition, the user space servicemay be configured to authenticate software based on one or more profilesand policies that may be specific to a particular developer profile, aparticular device identifier, a particular carrier, etc. Separatingthese logically and computationally complex processes from the trustedspace may improve software system reliability and performance andenables use of complex encryption and policy enforcement.

In order to illustrate embodiments of the present invention, FIGS. 1-7will now be presented below. FIG. 1 illustrates an overall systemdiagram in, which embodiments may be implemented. FIGS. 2-3 showembodiments of software components and exemplary profile for controllingexecution of software. FIG. 4 shows one example of a data flow betweensoftware components. FIGS. 5-6 then illustrate process flowcharts forexecuting software based on profiles. FIG. 7 is provided to illustrateone example of a mobile computing device. These figures will now befurther described below beginning with reference to FIG. 1.

FIG. 1 is one example of a computing environment, which allows for thedistribution of authorized software code to computing devices, which areconfigured to execute only authorized code. Computing devices 100 may beany number of different types of computing devices, including mobilecommunication devices, desktop computers, laptop computers, handheldcomputers, personal digital assistant (PDA) devices, mobile telephonedevices, media play device, and the like. The computing devices 100 maybe configured to require that any code executed on computing device 100be authorized by trusted authority 102. In other embodiments, morecomplex authorization schemes may be used, for example, unauthorizedsoftware may be executable but only for limited purposes or to accesslimited device resources while authorized software may be provided moreextensive access to resources of device 100.

As will be discussed in more detail below, authorization functionalitymay be provided by, or in conjunction with, an operating system ofdevice 100, which determines whether the code has been authorized by atrusted authority. If the code is authorized and verified as such, itmay be generally executed without any further system or userinteraction; if the code is not authorized, its ability to be executedon computing device 100 may be restricted or even prevented. In someembodiments, the computing device may alert the user that the code isnot authorized and ask the user if they still wish to execute theunauthorized code. In other embodiments, computing devices 100 may beconfigured to prevent unauthorized code from being executed at all,regardless of the user's wishes.

In some embodiments, trusted authority 102 may authorize software 106 bydigitally signing software 106. As is known in the art, a digitalsignature uses public key cryptography to ensure the integrity of data.For example, software developer 104 may provide trusted authority 102with compiled object code. Trusted authority 102 may then create adigital signature with its private key to the object code of software106 and may make the code available to computing devices 100.

When a request to execute the software may be made on computing device100, computing device 100 checks the digital signature of software 106to verify its authenticity and/or authorization. If the software isverified as being signed by trusted authority 102, software 106 may beexecuted on computing device 100. There are various ways for computingdevice 100 to check the digital signature of software 106 prior toexecution.

Software developer 104 may be any person or organization that writes,develops, tests, markets, sells, and/or distributes software to run oncomputing devices 100. In one embodiment, developer 104 may be a companyor enterprise developing software for use on devices 100 that itcontrols or manages.

As part of the software development cycle, software developer 104 maywish to test its software on computing devices that are similar to thoseon, which software 106 will be deployed in the field. Accordingly,software developer 104 may have one or more developer computing devices100, which allow the software developer to develop, test, and/orotherwise further the development of software 106.

Developer computing device 100 may be the same as the computing devices100 for, which developed software 106 may be intended. For example, if asoftware developer 104 may be writing software 106 to be run on a mobiletelephone platform such as the iPhone, for example, developer computingdevice 100 may be an iPhone. Similarly, if the computing device platform100 targeted for software 106 may be a media player, such as the iPodTouch, then developer computing device 100 may be an iPod touch. Byusing similar devices for testing and development, software developer104 may be able to more efficiently develop and test software prior todistributing the software to end user for use on computing devices 100.

During the software development process, the code in a softwareapplication may be changed frequently. Accordingly, as will be describedbelow, software developer may obtain and use developer access on one ormore of computing devices 100. This developer access profile may beinstalled on the developer computing devices 100, which allows thedeveloper to modify, recompile, and test their software on the devices100 without the need to request additional code signing services fromtrusted authority 102.

In some embodiments, developer computing devices 100 may also, inaddition to receiving developer access profiles, include development andtest related software such as a debugging, tracing, or profilingsoftware as part of a standard distribution installed on developercomputing devices 100, as part of a pre-provisioning process, or at anyother time. In some embodiments; developer computing devices 100 arepre-provisioned with such additional development related software. Inother embodiments, development related software may be installed on thedevice with, or in conjunction with, the developer access profile.

FIG. 2 is a block diagram providing one example of how developercomputing device 100 may be configured to utilize developer accessprofiles 208 to execute software modules 206 not signed by trustedauthority 102. As noted above, developer computer device 100 may be sametype of device as the computing devices 100 for, which software 106created by software developer 104 may be provided.

Software 106 may include one or more software modules 206 stored on, oraccessible by, device 100. In one embodiment, storage 209 of computingdevice 100 can include a computer-readable storage medium (volatileand/or non-volatile) that may be configured to store one or both ofsoftware modules 206 and profiles 208. Storage 209 may also beconfigured to store code of operating system 202, and may furtherinclude general purpose storage for device 100. The software modules 206may be stored temporarily in device 100 or permanently in device 100.

Developer computing device 100 may include an operating system. Theoperating system may be a well-known operating system, such as MacOS,Windows, Linux, Unix, Symbian, or the like. As discussed briefly above,a portion of the operation system, e.g., the kernel of operating system202 may be configured to require that code executed on device 100 beauthorized prior allowing it to be executed on the device. Thisauthorization may take the form of trusted authority 102 digitallysigning some or all of the software modules 206. In some embodiments,trusted authority 102 utilizes a code signing certificate, which may beused to verify the source and integrity of the signed computer code.

Kernel space of memory used by operating system 202 conceptually may beconsidered a trusted space. The trust may be established by boot-timeauthentication of the kernel. In one embodiment, computing device 100can include hardware support for providing the boot-time authenticationof the kernel space used by operating system 202 and its contents. Forexample, in one embodiment, the boot loader of computing device 100 mayauthenticate a signature of the kernel software prior to loading andbooting the kernel using, for example, suitable public key signatureverification.

A digital signature may include a digest that may be created, forexample, by performing a hash function on the software in order tocreate a message digest. In some embodiments, incremental code signingmay be used. The hash value may be a hash value generated for all or aparticular portion of the software. For example, in some embodiments,the software is divided into one or more units such as one or morepages. A hash value is generated for each unit or page of the software.The digest for the software in such embodiments includes a hash valuethat is generated for an array or table of the hash values of each codeor page. The message digest may be then encrypted using a privateencryption key associated with trusted authority 102. In one embodiment,the well known SHA-1 function may be used to generate the messagedigest. The encrypted message digest (also referred to as the signature)may be then appended to the one or more of the software modules 206.

In some embodiments, when a request is made on the device to executesoftware code, operating system 202 may process the request by verifyingthe source and integrity of the software code by validating the digitalsignature. If the source of the code is trusted authority 102, and theintegrity of the code has not been compromised, operating system 202 mayallow the code to run on computing device 100.

Developer computing device 100 may also include a device identifier 204.The device identifier 204 may take various forms. In one embodiment,device identifier 204 may be a serial number that uniquely identifiesdeveloper computing device 100. In other embodiments, device identifier204 may be a unique identifier generated by operating system 202.

As noted above, developer computing device 100 may also have a developeraccess profile 208, created by trusted authority 102. Developer accessprofile 208 may include a set of data that indicates that certaindevices are permitted to execute software not signed by trustedauthority 102. In one embodiment, a developer access profile 208 allowssoftware developers 104 to modify and recompile source code for theirsoftware modules 206, and then test the software modules 206 ondeveloper computing device 100 without needing to request additionalcode signing services from trusted authority 102. Instead, softwaredeveloper 104 may be permitted to digitally sign their software modules206 and run the software on those developer computing devices 100, whichhave developer access profiles 208 that specify that code signed bydeveloper 104 may be executed on device 100. In some embodiments, thedeveloper access profile may also specify certain operations thatdeveloper 104 may perform in testing the software modules 206. Forexample, a developer access profile 208 may specify that the softwaremodules 206 digitally signed by developer 104 may be debugged on thedeveloper computing devices 100. Developer computing device 100 may alsohave more than one developer access profile 208.

In some embodiments, developer access profile 208 may operate inconjunction with policy service 210. Policy service 210 may take theform of a daemon or other process running in a user (untrusted) memoryspace of the operating system, Policy service 210 may be furtherconfigured to enforce policies specified in the developer access profile208. For example, if a developer access profile 208 specifies that adeveloper can trace the operation of the software on the developmentdevice, but does not allow debugging, policy service 210 will allowtrace operations, but disallow running applications in debug mode.

Policy service 210 may be initially started by operating system 202,which may verify a cryptographically secured digest of the service 210before loading the service. Operating system 202 may maintain areference to the service 210 via an interprocess communication orsimilar suitable port. Thus, while the profile service 210 executes inan untrusted or user-mode space, the code of the profile service 210 maybe verified at execution to be signed by a trusted authority.

FIG. 3 is a more detailed view of the developer access profile 208. Asnoted above, developer access profile 208 may be a set of data stored inthe memory of device 100, which indicates that the device may bepermitted to execute software even though it has not been signed bytrusted authority 102. Developer access profile 208 can include deviceidentifier data 302, developer identifier data 304, and entitlement data306.

Device identifier data 302 specifies one or more device identifiers 302to, which the developer access profile 208 applies. In embodiments wherethe devices 100 are mobile telephone devices, device identifier data 302may include an array of mobile telephone device serial numbers.

Device identifier data 302 for a developer access profile 208 mayinclude one or more device identifiers 204 for different devices. In oneembodiment, device identifiers 204 may be specific identifiers, whichmay be represented as numeric or alphanumeric data, for specificdevices. In other embodiments, more generalized device identifying datamay be utilized. For example, some device vendors and/or manufacturersmay provide devices having device identifiers, which are specific to anorganization. For example, a device vendor and/or manufacturer maycustomize certain aspects of device identifiers 204 associated withdevices based on the organization to, which they are delivered.

Device identifier data 302 may include ranges of device identifiers,rather than listing each individual device identifier value. In stillother embodiments, a bit mask or wild card characters may be used tospecify that the developer access profile applies to all devices havingspecified identifier characteristics. In still other embodiments, deviceidentifier data 302 may specify that developer access profile 208applies to all devices. For example, in one such embodiment, softwaresigned by one or more of the developers identified in developeridentifier data 302 may be authorized to run on any device 100 upon,which the developer access profile 208 may be installed.

As noted, developer access profile 208 may further include developeridentifier data 304, which specifies software developers 104 to whom thedeveloper access profile 208 applies. Developer identifier data 304 maytake various forms. In some embodiments, developer identifier data 304may be public keys associated with software developers 104 covered bythe developer access profile 208. Other types of identifiers may also beused. In some embodiments, developer identifier data 304 may be storedin an array data structure stored within the developer access profile.Of course, any suitable data structures may be used.

Furthermore, developer access profile 208 may include entitlement data306. Entitlement data 306 may include data, which indicates the types ofoperations that are allowed for the software modules 206 signed bydevelopers identified in the developer identifier data 304 on thedevices 100 specified in device identifier data 302. A particulardeveloper access profile 208 may specify more than one developer 104 asbeing authorized to digitally sign code authorized by the developeraccess profile 208.

Entitlement data 306 may specify the types of access that are permittedfor applications signed by the developers 104 identified in thedeveloper identifier data 304 with respect to the devices 100 identifiedin device identifier data 302. The entitlement data 306 may take theform of key-value pairs. The values may include, for example, numeric,Boolean, or alphanumeric data. In one embodiment, the entitlement data306 may include an array or other data structure of predefined Booleanvariables, which are indicative of various specified entitlements.

In one embodiment, entitlement data 306 may include the capability to beexecuted. In one embodiment, a debug allowed entitlement may beincluded, that when set to “TRUE” in a particular profile indicates thatcode signed by developers 104 associated with developer access profile208 are permitted to execute software modules 206 on device 100 in adebug mode. If the debug mode allowed entitlement may be set to “FALSE,”and developer 104 attempts to run the software in debug mode on device100, policy service 210 may block the execution of the code. Other suchentitlements may include entitlement data that may be indicative of atrace-allowed entitlement. Trace-allowed entitlement may allow softwaremodules 206 digitally signed by developer 104 to be compiled andexecuted in trace mode on devices 100.

Other entitlements may control access to networking resources of device100, data, libraries, or applications that have security or privacyimplications such as address book data. In addition, other entitlementsmay control access to particular developer APIs including telephony,networking, address or phone storage, or multimedia APIs.

FIG. 4 is a block diagram illustrating illustrates relationships betweenevents that occur when a request may be received and processed by thesystem between software components of one embodiment of computing device100. As shown, in event 1, operating system 202, which can include atrusted space, may receive a request (in response to a user request toexecute the particular software module 206 or in response to a requestof another software component on device 100 to execute the particularsoftware module 206) to executed an identified software module 206. Inone embodiment, the request can include a reference to a directory orfile of the storage 209, which stores the executable instruction code ofsoftware module 206.

In event 2, operating system 202 may communicate a request toauthenticate software module 206 to policy service 210. In oneembodiment, the authentication request can include the reference to thestorage location in storage 209 associated with software module 206.Operating system 202 may also provide a digest of at least a portion ofsoftware module 206 to policy service 210. Alternatively, or inaddition, policy service 210 may generate a digest of all or a portionof software module 206. In one embodiment, the digest may be based ondigest values determined for each code page or each file associated withsoftware module 206. In one embodiment, requests to policy service 210may include other data such as specific entitlements that are to beenforced.

For example, operating system 202 may specify that the entitlement maybe an entitlement to execute, to debug, or to access specified systemresources. Operating system 202 or another portion of the operatingsystem of device 100 may be configured to request entitlementauthorization for access to specific networks such as a mobile telephonenetwork, a Bluetooth stack, or to specific capabilities of device 100such as to access a microphone, speaker, camera. or other I/O interfaceof device 100.

At event 5, policy service 210 may access one or more profiles 208associated with execution of software module 206. In one embodiment, theprofiles are accessed from storage 209. In one embodiment, profiles 208include a particular profile associated with a developer of softwaremodule 206. It may be to be recognized that while profiles are describedherein with respect to software developers 104 other than trustedauthority 102, access to software modules provided by trusted authority102, e.g., the device or operating system developer, may also becontrolled using the systems and methods described herein.

At event 5, policy service 210 may verify the execution rights ofsoftware module 206 based on the digest and/or profile 208. For example,policy service 210 may be configured to receive a signature associatedwith the digest of software module 206 and cryptographically verify thedigest. In one embodiment, policy service 210 may use a public keyassociated with a particular developer 104, and, which may be includedas part of profile 208, to verify the signature of the digest.

In one embodiment, to ensure that the profile and the developer key maybe trusted, policy service 210 cryptographically verifies that theprofile may be trusted by trusted authority 102. In this embodiment,policy service 210 may verify the profile by verifying a digest or othersignature of the profile (and its contents) using a public key oftrusted authority 102 that may be stored on device 100 or otherwiseaccessed, e.g., via a data network, by device 100.

Policy service 210 may be further configured to verify that softwaremodule 206 may be authorized for the particular device 100. For example,in one embodiment, profile 208 can include one or more deviceidentifiers or data for matching device identifiers (e.g., a mask orwildcard to match a specified group of devices 100).

Policy service 210 may compare the identifiers to an identifier securelymaintained by device 100 and authorizes the software module when theidentifier data of the policy 208 matches that of device 100. The deviceidentifier may include any data stored on the device that may be usedfor identification including a manufacturer serial number, device orsubscriber identifiers of a mobile telephone device such as anIntegrated Circuit Card ID (ICCID), International Mobile SubscriberIdentifier (IMSI) of a SIM card currently inserted into device 100, theInternational Mobile Equipment Identifier (IMEI) encoded on the device,an electronic serial number (ESN), or any other data suitable toidentify the devices 100 for, which a particular software module 206 maybe authorized.

Policy service 210 may be configured to authorize software module 206based on further entitlements or other capabilities as specified byprofiles 208. Executable or not-executable may be considered as anexample of am entitlement. Other entitlements may specify whether theparticular software module 206 may execute or access services based onone or more of profiles 208 and on any other policy that policy service210 may be configured to enforce.

Policy service 210 may be configured to execute in user space such thatthe policies and profiles enforced therein may be arbitrarily complexand subject to update without increasing the size of the kernel or otherprotected memory spaces and be more easily developed and revised withoutthe difficulties generally associated with kernel programming.

It is to be recognized that while FIG. 5 illustrates an example ofoperating system 202 determining whether a particular software module206 has an entitlement to be executed, the methods and systems describedherein may be used to authorize access to device hardware capabilities,other services of the kernel, other operating system services, orservices of another software module 208. For example, device 100 mayinclude a debugging or trace facility provided, for example, byoperating system 202 or other operating system component that may beonly authorized accordingly to policies enforced by the policy server210. For example, a debugger interface (not shown) may requestauthorization for debugging of a particular software module 206 usingthe system illustrated in FIG. 5 based on a debugging entitlementspecified in profile 208 associated with software module 206 or viaother policy.

Entitlements may be enforced via one or more policies associated withthe device. For example, a policy for enforcing entitlements may includeprocessing entitlement data in profiles as a white list, e.g., softwaremodule 206 may be authenticated for a particular such entitlement whenprofile 208 can include data indicating that entitlement exists for theparticular software module 206 and/or the particular device 100. Anotherpolicy may enforce entitlements based on a blacklist, e.g., softwaremodule 206 may be authenticated for a particular such entitlement unlessprofile 208 or applicable policy can include data negating thatentitlement for the particular software module 206 and/or the particulardevice 100. In another embodiment, device 100 may be configured with apolicy such that some entitlements may be configured to be enforced viaa white list while others are configured to be enforced via a blacklist.

Other policies may be included to more finely control particularentitlements or to resolve conflicting profile data. For example, in oneembodiment, a mobile service provider may include a particular carrierprofile 208 in devices for use on its network that further specifiesentitlements to particular device capabilities, e.g., voice network ordialer access, which may conflict with the developer profile 208 forparticular software modules 206. In such an event, a policy of device100 may specify that the entitlement specification of one of theprofiles controls.

In event 6, when policy service 210 may verify the entitlements and/orother execution rights of the software module 240, policy service 210provides operating system 202 or other client of policy service 210 withdata indicative of the entitlements of software module 206 and/or theentitlements for, which the request to authenticate was made. In event7, operating system 202 may then execute software module 206 inaccordance with the entitlement data received from policy service 210.

FIG. 5 is a flowchart illustrating one embodiment of a method 500 ofverifying entitlements of software modules 206 in devices 100. Themethod may begin at a block 502 in, which a trusted space of operatingsystem 202 receives a request to execute a particular software module206. In one embodiment, the trusted space may be established on startupof the device by a bootloader of device 100 that cryptographicallyverifies operating system 202 prior to loading.

In block 504, the trusted space process communicates data indicative ofsoftware module 206 to policy service 210 executing in untrusted space,but to, which trust has been granted upon initial execution of policyservice 210. The data may include a reference to a storage location ofsoftware module 206 and, optionally, data indicative of a particularentitlement being authenticated.

Next at block 506, policy service 210 authenticates software module 206.In one embodiment, policy service 210 authenticates software module 206based on cryptographic authentication. For example, policy service 210may authenticate software module 206 by verifying a digital signature ofsoftware module 206 using suitable cryptographic techniques such asasymmetric/public key encryption. Further, one or more entitlementsassociated with software module 206 may be authenticated similarcryptographic techniques. Further details of block 506 may be found withreference to FIG. 6.

Proceeding to block 508, policy service 210 communicates data indicativeof execution rights of the software module to the kernel of operatingsystem 202. The data may include a Boolean authentication response, dataindicative of one or more entitlements of software module 206, averified digest of software module 206, or any other suitable datarelative to the request.

In block 510, operating system 202 or other trusted process may thenexecute software module 206 or may perform services for software module206 based on the authenticated entitlements.

FIG. 6 is a flowchart illustrating block 506 of the method of FIG. 5 inmore detail. At block 602, policy service 210 may calculate a digest ofat least one file or other data structure associated with the executablecode of software module 206. The digest may be calculated using anysuitable hash algorithm, including, for example, SHA-1.

In block 604, policy service 210 may identify one or more profiles 208associated with software module 206 and/or device 100. In oneembodiment, profiles 208 can each include a signing key and dataindicative of entitlements of software module 206. For example, anentitlement may include a data structure in tabular form such asillustrated in Table 1.

TABLE 1 Example Profile Data Developer Signing Key 123555 Device ID1123FFF Device ID2 123FFF Executable TRUE Debuggable FALSECan_Access_Network TRUE Code Digest AAFF1144BB

Software modules 206 may be associated with profiles 208 via key-valuepairs of the profile that identify the digest (e.g., the “Code Digest”illustrated in Table 1) of software module 206. Profile 208 may furtherinclude a digital signature, e.g., a digest of the profilecryptographically signed by, for example, trusted authority 102. Next ata block 606, policy service 210 cryptographically verifies profile 208,e.g., by verifying that the cryptographic signature of the digest ofprofile 208 may be correct.

Moving to block 608, policy service 210 verifies that profile 208 may beapplicable to the particular device 100. In one embodiment, theverifying may include comparing the device identifier 204 of theparticular device 100 to the device identifiers listed in the signedprofile 208. The previous signature verification at the block 606 mayprovide assurance that the device identified in profile 208 have notbeen changed or modified without authorization.

Next at block 610, policy service 210 may identify execution rightsassociated with software module 206 based on profile(s) 208. In oneembodiment, the identifying can include accessing the entitlements ofeach profile.

In block 612, policy service 210 may verify that the entitlements to beverified for software module 206 are consistent with policies forcomputing device 100. In one embodiment, the verifying can includedetermining whether the requested entitlement may be included inprofiles 208 associated with software module 206 and policies of device100.

Proceeding to block 614, policy service 210 may then compare the digestvalue calculated at the block 602 to the signed digest of softwaremodule 206 and verify the cryptographic signature of the digest. It isto be recognized that depending on the embodiment, certain acts orevents of any of the methods described herein can be performed in adifferent sequence, may be added, merged, or left out all together(e.g., not all described acts or events are necessary for the practiceof the method). Moreover, in certain embodiments, acts or events may beperformed concurrently, e.g., through multi-threaded processing,interrupt processing, or multiple processors, rather than sequentially.

FIG. 7 is a block diagram illustrating an example of one of the devices100 embodied as a mobile device. Device 100 can include a processor 702that may be in communication with a memory 704. The network interface706 can include a receiver 724 and transmitter 726 configured tocommunicate via signals according to one or more suitable data and/orvoice communication systems. For example, network interface 708 may becommunicate to communicate voice and/or data over mobile telephonenetworks such as GSM, CDMA, CDMA2000, EDGE or, UMTS. Network interface706 may further include receiver/transmitters for other data networksincluding, for example, any IEEE 802.x network such as WiFi orBluetooth.

Device 100 may also include one or more of display 710, user inputdevice 712 such as a key, touch screen, or other suitable tactile inputdevice, loudspeaker 714 comprising a transducer adapted to provideaudible output based on a signal received over communication link 106and/or microphone 716 comprising a transducer adapted to provide audibleinput of a signal that may be transmitted over one or both of thecommunication links 106 and 108.

In one embodiment, input device 712 can include an accelerometer orother device configured to detect movement of the device. Device 100 mayoptionally include a battery 731 to provide power to one or morecomponents of device 100. Device 100 may include at least one of amobile handset, a personal digital assistant, a laptop computer, aheadset, a vehicle hands free device, or any other electronic device.For example, one or more aspects taught herein may be incorporated intoa phone (e.g., a mobile phone), a personal data assistant (“PDA”), anentertainment device (e.g., a music or video device), a headset (e.g.,headphones, an earpiece, etc.), a microphone, or any other electronicdevice. As described further below, in some embodiments, the device 100is implemented as a mobile device.

FIG. 8A illustrates an example mobile device 2500. The mobile device2500 can be, for example, a handheld computer, a personal digitalassistant, a cellular telephone, a network appliance, a camera, a smartphone, an enhanced general packet radio service (EGPRS) mobile phone, anetwork base station, a media player, a navigation device, an emaildevice, a game console, or a combination of any two or more of thesedata processing devices or other data processing devices.

Mobile Device Overview

In some implementations, the mobile device 2500 includes atouch-sensitive display 2502. The touch-sensitive display 2502 can beimplemented with liquid crystal display (LCD) technology, light emittingpolymer display (LPD) technology, or some other display technology. Thetouch-sensitive display 2502 can be sensitive to haptic and/or tactilecontact with a user.

In some implementations, the touch-sensitive display 2502 can comprise amulti-touch-sensitive display 2502. A multi-touch-sensitive display 2502can, for example, process multiple simultaneous touch points, includingprocessing data related to the pressure, degree, and/or position of eachtouch point. Such processing facilitates gestures and interactions withmultiple fingers, chording, and other interactions. Othertouch-sensitive display technologies can also be used, e.g., a displayin which contact is made using a stylus or other pointing device. Someexamples of multi-touch-sensitive display technology are described inU.S. Pat. Nos. 6,323,846, 6,570,557, 6,677,932, and 6,888,536, each ofwhich is incorporated by reference herein in its entirety.

In some implementations, the mobile device 2500 can display one or moregraphical user interfaces on the touch-sensitive display 2502 forproviding the user access to various system objects and for conveyinginformation to the user. In some implementations, the graphical userinterface can include one or more display objects 2504, 2506. In theexample shown, the display objects 2504, 2506, are graphicrepresentations of system objects. Some examples of system objectsinclude device functions, applications, windows, files, alerts, events,or other identifiable system objects.

Example Mobile Device Functionality

In some implementations, the mobile device 2500 can implement multipledevice functionalities, such as a telephony device, as indicated by aPhone object 2510; an e-mail device, as indicated by the Mail object2512; a map devices, as indicated by the Maps object 2514; a Wi-Fi basestation device (not shown); and a network video transmission and displaydevice, as indicated by the Web Video object 2516. In someimplementations, particular display objects 2504, e.g., the Phone object2510, the Mail object 2512, the Maps object 2514, and the Web Videoobject 2516, can be displayed in a menu bar 2518. In someimplementations, device functionalities can be accessed from a top-levelgraphical user interface, such as the graphical user interfaceillustrated in FIG. 8A. Touching one of the objects 2510, 2512, 2514, or2516 can, for example, invoke a corresponding functionality.

In some implementations, the mobile device 2500 can implement a networkdistribution functionality. For example, the functionality can enablethe user to take the mobile device 2500 and provide access to itsassociated network while traveling. In particular, the mobile device2500 can extend Internet access (e.g., Wi-Fi) to other wireless devicesin the vicinity. For example, mobile device 2500 can be configured as abase station for one or more devices. As such, mobile device 2500 cangrant or deny network access to other wireless devices.

In some implementations, upon invocation of a device functionality, thegraphical user interface of the mobile device 2500 changes, or isaugmented or replaced with another user interface or user interfaceelements, to facilitate user access to particular functions associatedwith the corresponding device functionality. For example, in response toa user touching the Phone object 2510, the graphical user interface ofthe touch-sensitive display 2502 may present display objects related tovarious phone functions; likewise, touching of the Mail object 2512 maycause the graphical user interface to present display objects related tovarious e-mail functions; touching the Maps object 2514 may cause thegraphical user interface to present display objects related to variousmaps functions; and touching the Web Video object 2516 may cause thegraphical user interface to present display objects related to variousweb video functions.

In some implementations, the top-level graphical user interfaceenvironment or state of FIG. 8A can be restored by pressing a button2520 located near the bottom of the mobile device 2500. In someimplementations, each corresponding device functionality may havecorresponding “home” display objects displayed on the touch-sensitivedisplay 2502, and the graphical user interface environment of FIG. 8Acan be restored by pressing the “home” display object.

In some implementations, the top-level graphical user interface caninclude additional display objects 2506, such as a short messagingservice (SMS) object 2530, a Calendar object 2532, a Photos object 2534,a Camera object 2536, a Calculator object 2538, a Stocks object 2540, aAddress Book object 2542, a Media object 2544, a Web object 2546, aVideo object 2548, a Settings object 2550, and a Notes object (notshown). Touching the SMS display object 2530 can, for example, invoke anSMS messaging environment and supporting functionality; likewise, eachselection of a display object 2532, 2534, 2536, 2538, 2540, 2542, 2544,2546, 2548, and 2550 can invoke a corresponding object environment andfunctionality.

Additional and/or different display objects can also be displayed in thegraphical user interface of FIG. 8A. For example, if the device 2500 isfunctioning as a base station for other devices, one or more“connection” objects may appear in the graphical user interface toindicate the connection. In some implementations, the display objects2506 can be configured by a user, e.g., a user may specify which displayobjects 2506 are displayed, and/or may download additional applicationsor other software that provides other functionalities and correspondingdisplay objects.

In some implementations, the mobile device 2500 can include one or moreinput/output (I/O) devices and/or sensor devices. For example, a speaker2560 and a microphone 2562 can be included to facilitate voice-enabledfunctionalities, such as phone and voice mail functions. In someimplementations, an up/down button 2584 for volume control of thespeaker 2560 and the microphone 2562 can be included. The mobile device2500 can also include an on/off button 2582 for a ring indicator ofincoming phone calls. In some implementations, a loud speaker 2564 canbe included to facilitate hands-free voice functionalities, such asspeaker phone functions. An audio jack 2566 can also be included for useof headphones and/or a microphone.

In some implementations, a proximity sensor 2568 can be included tofacilitate the detection of the user positioning the mobile device 2500proximate to the user's ear and, in response, to disengage thetouch-sensitive display 2502 to prevent accidental function invocations.In some implementations, the touch-sensitive display 2502 can be turnedoff to conserve additional power when the mobile device 2500 isproximate to the user's ear.

Other sensors can also be used. For example, in some implementations, anambient light sensor 2570 can be utilized to facilitate adjusting thebrightness of the touch-sensitive display 2502. In some implementations,an accelerometer 2572 can be utilized to detect movement of the mobiledevice 2500, as indicated by the directional arrow 2574. Accordingly,display objects and/or media can be presented according to a detectedorientation, e.g., portrait or landscape. In some implementations, themobile device 2500 may include circuitry and sensors for supporting alocation determining capability, such as that provided by the globalpositioning system (GPS) or other positioning systems (e.g., systemsusing Wi-Fi access points, television signals, cellular grids, UniformResource Locators (URLs)). In some implementations, a positioning system(e.g., a GPS receiver) can be integrated into the mobile device 2500 orprovided as a separate device that can be coupled to the mobile device2500 through an interface (e.g., port device 2590) to provide access tolocation-based services.

In some implementations, a port device 2590, e.g., a Universal SerialBus (USB) port, or a docking port, or some other wired port connection,can be included. The port device 2590 can, for example, be utilized toestablish a wired connection to other computing devices, such as othercommunication devices 2500, network access devices, a personal computer,a printer, a display screen, or other processing devices capable ofreceiving and/or transmitting data. In some implementations, the portdevice 2590 allows the mobile device 2500 to synchronize with a hostdevice using one or more protocols, such as, for example, the TCP/IP,HTTP, UDP and any other known protocol.

The mobile device 2500 can also include a camera lens and sensor 2580.In some implementations, the camera lens and sensor 2580 can be locatedon the back surface of the mobile device 2500. The camera can capturestill images and/or video.

The mobile device 2500 can also include one or more wirelesscommunication subsystems, such as an 802.11b/g communication device2586, and/or a Bluetooth™ communication device 2588. Other communicationprotocols can also be supported, including other 802.x communicationprotocols (e.g., WiMax, Wi-Fi, 3G), code division multiple access(COMA), global system for mobile communications (GSM), Enhanced Data GSMEnvironment (EDGE), etc.

Example Configurable Top-Level Graphical User Interface

FIG. 8B illustrates another example of configurable top-level graphicaluser interface of device 2500. The device 2500 can be configured todisplay a different set of display objects.

In some implementations, each of one or more system objects of device2500 has a set of system object attributes associated with it; and oneof the attributes determines whether a display object for the systemobject will be rendered in the top-level graphical user interface. Thisattribute can be set by the system automatically, or by a user throughcertain programs or system functionalities as described below. FIG. 8Bshows an example of how the Notes object 2552 (not shown in FIG. 8A) isadded to and the Web Video object 2516 is removed from the top graphicaluser interface of device 2500 (e.g. such as when the attributes of theNotes system object and the Web Video system object are modified).

Example Mobile Device Architecture

FIG. 9 is a block diagram 3000 of an example implementation of a mobiledevice (e.g., mobile device 2500). The mobile device can include amemory interface 3002, one or more data processors, image processorsand/or central processing units 3004, and a peripherals interface 3006.The memory interface 3002, the one or more processors 3004 and/or theperipherals interface 3006 can be separate components or can beintegrated in one or more integrated circuits. The various components inthe mobile device can be coupled by one or more communication buses orsignal lines.

Sensors, devices, and subsystems can be coupled to the peripheralsinterface 3006 to facilitate multiple functionalities. For example, amotion sensor 3010, a light sensor 3012, and a proximity sensor 3014 canbe coupled to the peripherals interface 3006 to facilitate theorientation, lighting, and proximity functions described with respect toFIG. 8A. Other sensors 3016 can also be connected to the peripheralsinterface 3006, such as a positioning system (e.g., GPS receiver), atemperature sensor, a biometric sensor, or other sensing device, tofacilitate related functionalities.

A camera subsystem 3020 and an optical sensor 3022, e.g., a chargedcoupled device (CCD) or a complementary metal-oxide semiconductor (CMOS)optical sensor, can be utilized to facilitate camera functions, such asrecording photographs and video clips.

Communication functions can be facilitated through one or more wirelesscommunication subsystems 3024, which can include radio frequencyreceivers and transmitters and/or optical (e.g., infrared) receivers andtransmitters. The specific design and implementation of thecommunication subsystem 3024 can depend on the communication network(s)over which the mobile device is intended to operate. For example, amobile device can include communication subsystems 3024 designed tooperate over a GSM network, a GPRS network, an EDGE network, a Wi-Fi orWiMax network, and a Bluetooth™ network. In particular, the wirelesscommunication subsystems 3024 may include hosting protocols such thatthe mobile device may be configured as a base station for other wirelessdevices.

An audio subsystem 3026 can be coupled to a speaker 3028 and amicrophone 3030 to facilitate voice-enabled functions, such as voicerecognition, voice replication, digital recording, and telephonyfunctions.

The I/O subsystem 3040 can include a touch screen controller 3042 and/orother input controller(s) 3044. The touch-screen controller 3042 can becoupled to a touch screen 3046. The touch screen 3046 and touch screencontroller 3042 can, for example, detect contact and movement or breakthereof using any of a plurality of touch sensitivity technologies,including but not limited to capacitive, resistive, infrared, andsurface acoustic wave technologies, as well as other proximity sensorarrays or other elements for determining one or more points of contactwith the touch screen 3046.

The other input controller(s) 3044 can be coupled to other input/controldevices 3048, such as one or more buttons, rocker switches, thumb-wheel,infrared port, USB port, and/or a pointer device such as a stylus. Theone or more buttons (not shown) can include an up/down button for volumecontrol of the speaker 3028 and/or the microphone 3030.

In one implementation, a pressing of the button for a first duration maydisengage a lock of the touch screen 3046; and a pressing of the buttonfor a second duration that is longer than the first duration may turnpower to the mobile device on or off. The user may be able to customizea functionality of one or more of the buttons. The touch screen 3046can, for example, also be used to implement virtual or soft buttonsand/or a keyboard.

In some implementations, the mobile device can present recorded audioand/or video files, such as MP3, AAC, and MPEG files. In someimplementations, the mobile device can include the functionality of anMP3 player, such as an iPod™. The mobile device may, therefore, includea 32-pin connector that is compatible with the iPod™. Other input/outputand control devices can also be used.

The memory interface 3002 can be coupled to memory 3050. The memory 3050can include high-speed random access memory and/or non-volatile memory,such as one or more magnetic disk storage devices, one or more opticalstorage devices, and/or flash memory (e.g., NAND, NOR). The memory 3050can store an operating system 3052, such as Darwin, RTXC, LINUX, UNIX,OS X, WINDOWS, or an embedded operating system such as VxWorks. Theoperating system 3052 may include instructions for handling basic systemservices and for performing hardware dependent tasks. In someimplementations, the operating system 3052 can be a kernel (e.g., UNIXkernel).

The memory 3050 may also store communication instructions 3054 tofacilitate communicating with one or more additional devices, one ormore computers and/or one or more servers. The memory 3050 may includegraphical user interface instructions 3056 to facilitate graphic userinterface processing; sensor processing instructions 3058 to facilitatesensor-related processing and functions; phone instructions 3060 tofacilitate phone-related processes and functions; electronic messaginginstructions 3062 to facilitate electronic-messaging related processesand functions; web browsing instructions 3064 to facilitate webbrowsing-related processes and functions; media processing instructions3066 to facilitate media processing-related processes and functions;GPS/Navigation instructions 3068 to facilitate GPS andnavigation-related processes and instructions; camera instructions 3070to facilitate camera-related processes and functions; and/or othersoftware instructions 3072 to facilitate other processes and functions.The memory 3050 may also store other software instructions (not shown),such as web video instructions to facilitate web video-related processesand functions; and/or web shopping instructions to facilitate webshopping-related processes and functions. In some implementations, themedia processing instructions 3066 are divided into audio processinginstructions and video processing instructions to facilitate audioprocessing-related processes and functions and video processing-relatedprocesses and functions, respectively. An activation record andInternational Mobile Equipment Identity (IMEI) 3074 or similar hardwareidentifier can also be stored in memory 3050.

In view of the above, one will recognize that embodiments overcomeproblems that may include enforcing execution profiles so as to allowdevelopers to develop and test applications in an execution environmentwhere applications are generally provided by one or more other trustedentities. In addition, device providers, such as enterprises, may beprovided the flexibility to distribute custom developed applicationswithout distributing such applications via the trusted entities.

Those of skill will recognize that the various illustrative logicalblocks, modules, circuits, and algorithm steps described in connectionwith the embodiments disclosed herein may be implemented as electronichardware, computer software, or combinations of both. To clearlyillustrate this interchangeability of hardware and software, variousillustrative components, blocks, modules, circuits, and steps have beendescribed above generally in terms of their functionality. Whether suchfunctionality is implemented as hardware or software depends upon theparticular application and design constraints imposed on the overallsystem. Skilled artisans may implement the described functionality invarying ways for each particular application, but such implementationdecisions should not be interpreted as causing a departure from thescope of the present invention.

The various illustrative logical blocks, modules, and circuits describedin connection with the embodiments disclosed herein may be implementedor performed with a general purpose processor, a digital signalprocessor (DSP), an application specific integrated circuit (ASIC), afield programmable gate array (FPGA) or other programmable logic device,discrete gate or transistor logic, discrete hardware components, or anycombination thereof designed to perform the functions described herein.A general purpose processor may be a microprocessor, but in thealternative, the processor may be any conventional processor,controller, microcontroller, or state machine. A processor may also beimplemented as a combination of computing devices, e.g., a combinationof a DSP and a microprocessor, a plurality of microprocessors, one ormore microprocessors in conjunction with a DSP core, or any other suchconfiguration.

The steps of a method or algorithm described in connection with theembodiments disclosed herein may be embodied directly in hardware, in asoftware module executed by a processor, or in a combination of the two.A software module may reside in RAM memory, flash memory, ROM memory,EPROM memory, EEPROM memory, registers, hard disk, a removable disk, aCD-ROM, or any other form of storage medium known in the art. Anexemplary storage medium is coupled to the processor such the processorcan read information from, and write information to, the storage medium.In the alternative, the storage medium may be integral to the processor.The processor and the storage medium may reside in an ASIC. The ASIC mayreside in a user terminal. In the alternative, the processor and thestorage medium may reside as discrete components in a user terminal.

While the above detailed description has shown, described, and pointedout novel features of the invention as applied to various embodiments,it will be understood that various omissions, substitutions, and changesin the form and details of the device or process illustrated may be madeby those skilled in the art without departing from the spirit of theinvention. As will be recognized, the present invention may be embodiedwithin a form that does not provide all of the features and benefits setforth herein, as some features may be used or practiced separately fromothers. The scope of the invention is indicated by the appended claimsrather than by the foregoing description. All changes, which come withinthe meaning and range of equivalency of the claims are to be embracedwithin their scope.

What is claimed is:
 1. A computerized method of authorizing software,the method comprising: receiving, in a trusted space of a processor, arequest to execute a software module stored on the electronic device;communicating data indicative of the software module to a serviceexecuting in an unfrosted space of the processor; authenticating atleast one entitlement of the software module by the service;communicating data indicative of the authenticated entitlement to thetrusted space; and executing the software module based on theentitlement.